-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: preflight scripts for laboratory #5564
base: main
Are you sure you want to change the base?
Conversation
- [ ] replace by `app/feed.xml/route.ts` route handler - [ ] remove `graymatter` dependency - [ ] refactor `product-updates` to allow to have changelog as folder
I think this feature deserves a screen cast to review? |
@@ -27,7 +27,7 @@ jobs: | |||
- name: setup environment | |||
uses: ./.github/actions/setup | |||
with: | |||
codegen: false | |||
codegen: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we now use the integration test seed here which uses client preset.
'lab-worker.staging.graphql-hive.com', | ||
'cdn.staging.graphql-hive.com', | ||
// Dev | ||
'dev.graphql-hive.com', | ||
'app.dev.graphql-hive.com', | ||
'lab-worker.dev.graphql-hive.com', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no longer needed, we don't need to run on a different domain to isolate the worker.
@@ -14,6 +14,67 @@ export class Proxy { | |||
private staticIp?: { address?: string; aksReservedIpResourceGroup?: string }, | |||
) {} | |||
|
|||
registerInternalProxy( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dotansimha we can remove this, right?
docker/.end2end.env
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I deleted this file since it is almost identical with the existing env file we have in the integration tests folder except the SUPERTOKENS_API_KEY
xD
I unified both, in the future we can probably even use docker-compose.integration-tests.yml
for end2end tests instead of having yet another file.
supertokens: | ||
ports: | ||
- '3567:3567' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
needs to be exposed for the seed script
@@ -131,6 +131,7 @@ const createSession = async ( | |||
*/ | |||
return { | |||
access_token: data.accessToken.token, | |||
refresh_token: data.refreshToken.token, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need this in cypress for "logging" in the user
const pg = { | ||
user: ensureEnv('POSTGRES_USER'), | ||
password: ensureEnv('POSTGRES_PASSWORD'), | ||
host: ensureEnv('POSTGRES_HOST'), | ||
port: ensureEnv('POSTGRES_PORT'), | ||
db: ensureEnv('POSTGRES_DB'), | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Delaying this assertion because it is not required for seeding within the e2e tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Inspired by @jasonkuhrt I tried some namespace action. 😄
I kind of like that types are isolated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@n1ru4l @dotansimha per some of our other recent discussions, one limitation of TS namespace
UNLIKE ESM is that you cannot export * from ...
. Its a significant limitation in some cases, enough not to use them (for example consider my Typebox
namespace in my PR). Another reason to not use them, as mentioned before, is that, again UNLIKE ESM, namespace
does not support tree shaking since its actually not a static ECMA feature.
As previously mentioned, IMO the nirvana would be the tc39 inline modules spec (assuming it does what I think it will do haha). It would decouple the concept of module and file, replacing all the use-cases of namespace
, while bringing symmetry with ESM such as the aforementioned export * from ...
and tree shaking (should, since its a static structure, so bundlers should be able to track it just like they do with ESM file-modules today).
Also, currently, TS unfortunately has poor autocomplete for ESM based namespaces. Truly annoying because it means we are stuck, in some cases, between this choice:
- Good IDE experience
- Good runtime characteristics (tree shaking namely)
Anyways, I'm pretty passionate and nerdy about this stuff as you can see... 🫶. My interest comes from my belief that namespaces are hugely important to maintainable and readable code.
e2e: { | ||
setupNodeEvents(on) { | ||
on('task', { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: this is executed on a different thread than the tests, so we cannot simply inject the whole seed object into the tests. For now, we only need these seeds. So it's fine. Later one we might want to investigate into another solution for injecting the seed.
This reverts commit fc178c0.
@@ -44,7 +44,7 @@ | |||
"seed": "tsx scripts/seed-local-env.ts", | |||
"start": "pnpm run local:setup", | |||
"test": "vitest", | |||
"test:e2e": "CYPRESS_BASE_URL=$HIVE_APP_BASE_URL cypress run", | |||
"test:e2e": "CYPRESS_BASE_URL=$HIVE_APP_BASE_URL cypress run --browser chrome", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed that the chrome is not used by default on CI. Both locally and on CI chrome seems to be less flaky.
closes #3612
Preview Link for docs: #5564 (comment)